The 80% problem

Is Pair programming really the solution?

Someone recently posted on LinkedIn claiming that pair programming—or as they phrased it, "team programming"—is a better use of time. They noted that, as engineers, we spend 80% or more of our time reading code.   Their argument? If we wrote code as a team, we could reduce that hefty 80% of time spent reading it  (For this post, I include debugging in that because, let's face it, debugging is just reading code while wondering which past version of yourself deserves the blame). 

Let’s start with the obvious: there’s no argument about the 80%. We do spend more time reading code than writing it. In a standard 40-hour work week, 80% is a whopping 32 hours of reading and debugging.

Here’s why understanding this matters: even a 10% improvement in reading efficiency translates into an additional 3.2 hours of coding time. That’s half a workday—a pretty compelling reason to care about optimizing how we read code. In other words, that extra 3.2 hours of improvement represents a 50% boost in our “coding output” column. Sounds great, right?

Well, hold on to your keyboards because here’s the twist: pair programming isn’t the answer.

In the best-case scenario, pair programming gives you the same amount of output for the sum of the effort.

And consider this: when two programmers work together, is each one contributing 100% of their productivity? Probably not. One is likely leading while the other plays the role of an overly polite shadow, nodding along and occasionally asking, “Wait, why did you name this variable foo?”

There may be some benefit of pair programming like knowledge sharing.  But cost-effective? Not so much. For it to truly pay off, each person would have to contribute more than 100% of their individual effort. And unless your team is powered by coffee stronger than rocket fuel, that’s just not sustainable.

A lot of our programming practices, though well-intentioned, don’t actually help with that 80% of time spent reading code. In fact, some might even make it worse.

I was initially planning to dive into my own strategies for improving that 80%, but this post is long enough already. Plus, who doesn’t love a good cliffhanger? I’ll cover those ideas in future posts. In the meantime, feel free to browse what I’ve already shared and let me know your thoughts.

Let’s Hear From You

Do you find value in pair programming or think it’s just a glorified way to procrastinate in pairs? How do you tackle the 80% problem? Drop your thoughts through my contact page—I’m all ears (and maybe eyes, since I’ll be reading them).